It allows you to get prelude shapes when getting the AST.

Can you please elaborate on why is this needed? What use case are you trying to solve that needs the prelude shapes in the serialized model?

Regardless of other implementations, I think being able to see the prelude shapes in the output of AST is useful, especially if those implementations need to see those definitions, or if you want a complete closure of the model to generate against.

The closure I think is important so that implementations don't need to know about preludes at all. When I'm given a model, I expect that model to be complete. I otherwise need to special case every prelude ID. For example, if a structure targets a string, I can't visit that string, I need to inspect all keys of the structure and ignore prelude keys. If the string prelude is in the model, then I can iterate all members agnostically and check their type field, and visit shapes that way.

Regardless of other implementations, I think being able to see the prelude shapes in the output of AST is useful, especially if those implementations need to see those definitions, or if you want a complete closure of the model to generate against.

I don't feel like this is useful enough to justify this change, in particular because, as discussed offline, the prelude shapes need to be known ahead of time anyway. It's also possible to configure the build to include them without any need for this change, see here.

How do you use a smithy-build.json with the AST command?

How do you use a smithy-build.json with the AST command?

In general you can use -c as in

smithy ast -c smithy-build.json

But it doesn't seem to work as expected, not sure why.

Yes, I tried that originally. I also don't know why a build config file shouldn't influence the AST command, so I ended up opening this PR. If smithy build can send me a complete model with prelude if configured to do so, AST should as well.

This discrepancy is because the ast command does no transformation, projecting, or plugin application from the smithy-build.json file – it's solely used for sources/imports. We can include this option, it seems fine to do so given that ast doesn't use the rest of the config file where it could be sourced from.

However, your implementation should probably be providing its own prelude. Requiring every provided model to bring it along is bound to create conflicts when a minor part of it changes (new or updated traits, etc.) and two models with different preludes are brought together.

Thanks for the input. What do you mean? I thought this implementation just uses the same prelude that the other transforms rely on. If you have something different in mind, please take over the PR.

Apologies, should have been clearer - that second paragraph is directed at this from the PR description:

Implementations that do not use Smithy in Java will need a way to get prelude shapes in the JSON model. Otherwise, special casing is necessary to handle prelude shapes.

I see. Yes, in Smithy Ruby, I have my own "prelude" hacked into the generator - where if a prelude shape such as smithy.api#String doesn't exist in the model, it has a default fallback, but I really think models should be complete. If the prelude is included in the model (using this option), then my fallback is not used, and it still resolves.

This PR should probably include a test if you don't have one already.

Thanks for looking into this.